home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 1 (Walnut Creek)
/
Aminet - June 1993 [Walnut Creek].iso
/
aminet
/
util
/
misc
/
copymemquicker22.lha
/
CopyMemQuicker.DOC
< prev
next >
Wrap
Text File
|
1992-02-12
|
3KB
|
61 lines
CopyMemQuicker 2.2 (11 Feb 1992)
Copyright © 1991, 1992 Arthur Hagen
Parts of code:
Copyright © 1985-1991 Commodore Business Machines Ltd.
======================================================
Posted to the Public Domain!
(by permission of Commodore Norge A/S)
Just another small thingy to put in your Amigas S:Startup-Sequence.
This one will patch the exec.library functions CopyMem and CopyMemQuick
to become faster than the regular ones. These functions are two of the
cornerstone functions of the operating system, so most programs should
benefit from this patch. I really wonder why the routines never were
optimised by Commodore in the first place!
Known bugs: None. Should work with all versions of the O/S from
KickStart 1.2 upto and including 2.04, and with all processors from the
68000 upto and including the 68040.
Even so, SOME virus killers might just report this patch as a virus -
it isn't. And, remember, if you use this program, you do it totally at
your own risk - I will under no circumstances be held responsible for
what this program does to any system (It should be 100% compatible with
ye olde routines, though - the only difference is that this code won't
bug out if you try to copy 0 bytes, the original code does...).
Speed increases may vary according to the processor, but some cycles
should be should be shaved off on all systems. My 68010-based system
experiences some 3-50% boost with CopyMemQuicker, with the peak for a
small number of bytes.
The patch is optimised for all 68k processors (except the 68008), and
relies upon the loop-mode and instruction cache for the faster pro-
cessors, but the routines might be optimised further by longword-
aligning some parts of the code for the faster processors with 32-bits
ram. Feel free to do so...
Usage:
1> CopyMemQuicker
This will act like a switch, and turns the program on/off (but I
don't know why it ever should be turned off). The memory used will NOT
be freed when turning the function off, as some other part of your
multitasking system might still be using the routine. I think you
could live with the loss of 2-300 bytes, though...
To test the routine on your machine, run "testit" from CLI (This
requires that you have version 2.0 of the O/S). It might take some
time to complete (depending on the processor), but should give fairly
accurate test results. (The reason for the test taking longer time
than the figures printed on-screen indicate, is that the time to
execute the timing loop itself is timed and deducted before printing
(to give as accurate a result as possible).)
There WAS a severe bug in versions 1.4 and 1.5 of this patch, which
caused a guru on all machines except those fitted with a 68010. This
was due to a bug in the Aztec assembler, which could not handle ad-
dresses like "*-2" properly. The bug has been worked around, and the
current version has been properly tested before release. Sorry!
Enjoy,
*Art